Systems and methods for data validation and transformation of data in a zero-trust environment

ABSTRACT

Systems and methods for the validation and transform of data for processing by an algorithm is provided. In some embodiments, input data is cleaned, and then the domain of the data is determined. The domain of the data refers to the data type. A validation of the data occurs. The validation is for the ranges and distribution that the data should have, according to the domain, versus the actual data ranges and distribution. Data that fails the validation undergo a transform step and then are re-validated. This process is iterative until the data set passes validation. Transforms are first selected based upon the data domain that was determined prior. Transforms that fit a range requirement, or a distribution type may be selected. In alternate embodiments, machine learning (ML) may be employed to train models, exclusive to a given domain, to identify needed transforms.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit and is a non-provisional of U.S.Provisional Application No. 63/293,723 filed Dec. 24, 2021 entitled“Systems And Methods For Data Validation And Transform, DataObfuscation, And Algorithm Validation In A Zero-Trust Environment”,which application is incorporated in its entirety by this reference.

BACKGROUND

The present invention relates in general to the field of zero-trustcomputing, and more specifically to methods, computer programs andsystems for the transformation, annotation and validation of datasetsand algorithms within such systems. Such systems and methods areparticularly useful in situations where algorithm developers wish tomaintain secrecy of their algorithms, and the data being processed ishighly sensitive, such as protected health information. For avoidance ofdoubt, an algorithm may include a model, code, pseudo-code, source code,or the like.

Within certain fields, there is a distinguishment between the developersof algorithms (often machine learning of artificial intelligencealgorithms), and the stewards of the data that said algorithms areintended to operate with and be trained by. On its surface this seems tobe an easily solved problem of merely sharing either the algorithm orthe data that it is intended to operate with. However, in reality, thereis often a strong need to keep the data and the algorithm secret. Forexample, the companies developing their algorithms may have the bulk oftheir intellectual property tied into the software comprising thealgorithm. For many of these companies, their entire value may becentered in their proprietary algorithms. Sharing such sensitive data isa real risk to these companies, as the leakage of the software base codecould eliminate their competitive advantage overnight.

One could imagine that instead, the data could be provided to thealgorithm developer for running their proprietary algorithms andgeneration of the attendant reports. However, the problem with thismethodology is two-fold. Firstly, often the datasets for processing andextremely large, requiring significant time to transfer the data fromthe data steward to the algorithm developer. Indeed, sometimes thedatasets involved consume petabytes of data. The fastest fiber opticsinternet speed in the US is 2,000 MB/second. At this speed, transferringa petabyte of data can take nearly seven days to complete. It should benoted that most commercial internet speeds are a fraction of thismaximum fiber optic speed.

The second reason that the datasets are not readily shared with thealgorithm developers is that the data itself may be secret in somemanner. For example, the data could also be proprietary, being of asignificant asset value. Moreover, the data may be subject to somecontrol or regulation. This is particularly true in the case of medicalinformation. Protected health information, or PHI, for example, issubject to a myriad of laws, such as HIPAA, that include strictrequirements on the sharing of PHI, and are subject to significant finesif such requirements are not adhered to.

Healthcare related information is of particular focus of thisapplication. Of all the global stored data, about 30% resides inhealthcare. This data provides a treasure trove of information foralgorithm developers to train their specific algorithm models (AI orotherwise), and allows for the identification of correlations andassociations within datasets. Such data processing allows advancementsin the identification of individual pathologies, public health trends,treatment success metrics, and the like. Such output data from therunning of these algorithms may be invaluable to individual clinicians,healthcare institutions, and private companies (such as pharmaceuticaland biotechnology companies). At the same time, the adoption of clinicalAI has been slow. More than 12,000 life-science papers described AI andML in 2019 alone. Yet the U.S. Food and Drug Administration (FDA) hasonly approved only slightly more than 30 AI/ML-based medicaltechnologies to date. Data access is a major barrier to clinicalapproval. The FDA requires proof that a model works across the entirepopulation. However, privacy protections make it challenging to accessenough diverse data to accomplish this goal.

To make the situation even more complicated, there is often errors inPHI (or most datasets for that matter). These errors can causesignificant problems for the processing by an algorithm. Traditionally,the algorithm developer would validate data before running it in thealgorithm to limit the impact of such errors. In these situations wherethe data will not (or cannot) be shared, another method (beyondexhaustive manual review) must be employed to ensure proper algorithmoperation.

Conversely, as the data stewards do not have access to the algorithm, itis often very difficult to validate the proper operation of thealgorithm. Without assurances that the algorithm is operating asintended, healthcare providers, researchers, and biotechnologycompanies, and rightfully hesitant to make important decisions basedupon algorithm outputs.

Given that there is great value in the operation of secret algorithms ondata that also must remain secret, and yet the need to verify andtransform the data being operated upon, and validation of the algorithmemployed, there is a significant need for systems and methods that allowfor such zero-trust operations while providing validations and whenneeded, alterations of the inputted data. Such systems and methodsenable sensitive data to be analyzed in a secure environment, providingthe needed outputs, while maintaining secrecy of both the algorithmsinvolved, as well as the data itself.

SUMMARY

The present systems and methods relate to the processing of secret databy secret algorithms in a secure and zero-trust environment, whilevalidating the data, transforming it when necessary, and validating thealgorithm such that all the parties can be sure the operations of thealgorithms upon the intended data set are performed properly. Suchsystems and methods enable improvements in the ability to identifyassociations in data that traditionally require some sort of risk to thealgorithm developer, the data steward, or both parties. An example ofhow such a system can benefit patients is that using a model, forexample, a clinical decision support tool can be developed, intended toassist providers in targeting patients with diabetic retinopathy tobenefit from treatment.

In some embodiments, input data is cleaned, and then the domain of thedata is determined. The domain of the data refers to the data type. Avalidation of the data occurs. The validation is for the ranges anddistribution that the data should have, according to the domain, versusthe actual data ranges and distribution. Data that fails the validationundergo a transform step and then are re-validated. This process isiterative until the data set passes validation.

The transform step may include identification of a transform and thenapplication of the identified transform. Initially, sets of transformsare first selected based upon the data domain that was determined prior.Transforms that fit a range requirement, or a distribution type may beselected. In alternate embodiments, machine learning (ML) may beemployed to train models, exclusive to a given domain, to identifyneeded transforms. The appropriate model (again selected based upondomain) is then used to process the input data to identify whichtransform is needed.

After all transforms and validations occur, generally a human ispresented with the initial data, the transformed data, and anexplanation of how the data has been altered. This data can then beutilized for a number of downstream applications, including processingwithin a zero-trust environment by an algorithm.

Note that the various features of the present invention described abovemay be practiced alone or in combination. These and other features ofthe present invention will be described in more detail below in thedetailed description of the invention and in conjunction with thefollowing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the present invention may be more clearly ascertained,some embodiments will now be described, by way of example, withreference to the accompanying drawings, in which:

FIGS. 1A and 1B are example block diagrams of a system for zero trustcomputing of data by an algorithm, in accordance with some embodiment;

FIG. 2 is an example block diagram showing the core management system,in accordance with some embodiment;

FIG. 3 is an example block diagram showing a first model for thezero-trust data flow, in accordance with some embodiment;

FIG. 4 is an example block diagram showing a second model for thezero-trust data flow, in accordance with some embodiment;

FIG. 5 is an example block diagram showing a third model for thezero-trust data flow, in accordance with some embodiment;

FIG. 6 is a flowchart for an example process for the operation of thezero-trust data processing system, in accordance with some embodiment;

FIG. 7A a flowchart for an example process of acquiring and curatingdata, in accordance with some embodiment;

FIG. 7B a flowchart for an example process of onboarding a new host datasteward, in accordance with some embodiment;

FIG. 8 is a flowchart for an example process of encapsulating thealgorithm and data, in accordance with some embodiment;

FIG. 9 is a flowchart for an example process of a first model ofalgorithm encryption and handling, in accordance with some embodiment;

FIG. 10 is a flowchart for an example process of a second model ofalgorithm encryption and handling, in accordance with some embodiments;

FIG. 11 is a flowchart for an example process of a third model ofalgorithm encryption and handling, in accordance with some embodiments;

FIG. 12 is an example block diagram showing the training of the modelwithin a zero-trust environment, in accordance with some embodiments;

FIG. 13 is a flowchart for an example process of training of the modelwithin a zero-trust environment, in accordance with some embodiments;

FIG. 14 is an example block diagram showing the key management for therunning of an algorithm on a computing capsule within a semi-trustenvironment, in accordance with some embodiments;

FIG. 15 is a flowchart for an example process of key management for therunning of an algorithm on a computing capsule within a semi-trustenvironment, in accordance with some embodiments;

FIG. 16 is an example block diagram showing the running of an algorithmwithin a zero-trust environment with data reporting obfuscation, inaccordance with some embodiments;

FIG. 17 is an example block diagram showing the dual algorithm operationon a single dataset within a zero-trust environment, in accordance withsome embodiments;

FIG. 18 is an example block diagram showing the chained running ofalgorithms on sets of data within multiple zero-trust environments, inaccordance with some embodiments;

FIG. 19 is a flow diagram for the example process of running of analgorithm within a zero-trust environment with data reportingobfuscation, in accordance with some embodiments;

FIG. 20 is a flow diagram for the example process of dual algorithmoperation on a single dataset within a zero-trust environment, inaccordance with some embodiments;

FIG. 21 is a flow diagram for the example process of chained running ofalgorithms on sets of data within multiple zero-trust environments, inaccordance with some embodiments;

FIG. 22 is a flow diagram for the example process of linking of multipleprocessed datasets within multiple zero-trust environments, inaccordance with some embodiments;

FIGS. 23A and 23B are flow diagrams showing two alternate exampleprocesses of matching identifying information between datasets, inaccordance with some embodiments;

FIGS. 24A and 24B are block diagrams for the environment forconsolidated data processing leveraging a synthetic data steward node,in accordance with some embodiments;

FIG. 24C is a block diagram of the various toolsets available to thedata steward, in accordance with some embodiments;

FIG. 25 is a block diagram of the validation and transformation tooling,in accordance with some embodiments;

FIG. 26 is a flow diagram for the example process of validating andtransforming datasets within zero-trust environments, in accordance withsome embodiments;

FIGS. 27A and 27B are flow diagrams for alternate example processes ofidentifying needed transforms of a dataset, in accordance with someembodiments;

FIGS. 28A and 28B are a flow diagrams for the example process of dataobfuscation, in accordance with some embodiments;

FIG. 29 is a flow diagram for the example process of algorithmvalidation, in accordance with some embodiments;

FIG. 30 is a flow diagram for the example process of annotationvalidation, in accordance with some embodiments; and

FIGS. 31A and 31B are illustrations of computer systems capable ofimplementing the zero-trust computing, in accordance with someembodiments.

DETAILED DESCRIPTION

The present invention will now be described in detail with reference toseveral embodiments thereof as illustrated in the accompanying drawings.In the following description, numerous specific details are set forth inorder to provide a thorough understanding of embodiments of the presentinvention. It will be apparent, however, to one skilled in the art, thatembodiments may be practiced without some or all of these specificdetails. In other instances, well known process steps and/or structureshave not been described in detail in order to not unnecessarily obscurethe present invention. The features and advantages of embodiments may bebetter understood with reference to the drawings and discussions thatfollow.

The present invention relates to systems and methods for the zero-trustapplication on one or more algorithms processing sensitive datasets.Such systems and methods may be applied to any given dataset, but mayhave particular utility within the healthcare setting, where the data isextremely sensitive. As such, the following descriptions will center onhealthcare use cases. This particular focus, however, should notartificially limit the scope of the invention. For example, theinformation processed may include sensitive industry information,payroll or other personally identifiable information, or the like. Assuch, while much of the disclosure will refer to protected healthinformation (PHI) it should be understood that this may actually referto any sensitive type of data. Likewise, while the data stewards aregenerally thought to be a hospital or other healthcare entity, thesedata stewards may in reality be any entity that has and wishes toprocess their data within a zero-trust environment.

In some embodiments, the following disclosure will focus upon the term“algorithm”. It should be understood that an algorithm may includemachine learning (ML) models, neural network models, or other artificialintelligence (AI) models. However, algorithms may also apply to moremundane model types, such as linear models, least mean squares, or anyother mathematical functions that convert one or more input values, andresults in one or more output models.

Also, in some embodiments of the disclosure, the terms “node”,“infrastructure” and “enclave” may be utilized. These terms are intendedto be used interchangeably and indicate a computing architecture that islogically distinct (and often physically isolated). In no way does theutilization of one such term limit the scope of the disclosure, andthese terms should be read interchangeably. To facilitate discussions,FIG. 1A is an example of a zero-trust infrastructure, shown generally at100 a. This infrastructure includes one or more algorithm developers120a-x which generate one or more algorithms for processing of data,which in this case is held by one or more data stewards 160a-y. Thealgorithm developers are generally companies that specialize in dataanalysis, and are often highly specialized in the types of data that areapplicable to their given models/algorithms. However, sometimes thealgorithm developers may be individuals, universities, governmentagencies, or the like. By uncovering powerful insights in vast amountsof information, AI and machine learning (ML) can improve care, increaseefficiency, and reduce costs. For example, AI analysis of chest x-rayspredicted the progression of critical illness in COVID-19. In anotherexample, an image-based deep learning model developed at MIT can predictbreast cancer up to five years in advance. And yet another example is analgorithm developed at University of California San Francisco, which candetect pneumothorax (collapsed lung) from CT scans, helping prioritizeand treat patients with this life-threatening condition—the firstalgorithm embedded in a medical device to achieve FDA approval.

Likewise, the data stewards may include public and private hospitals,companies, universities, governmental agencies, or the like. Indeed,virtually any entity with access to sensitive data that is to beanalyzed may be a data steward.

The generated algorithms are encrypted at the algorithm developer inwhole, or in part, before transmitting to the data stewards, in thisexample ecosystem. The algorithms are transferred via a core managementsystem 140, which may supplement or transform the data using a localizeddatastore 150. The core management system also handles routing anddeployment of the algorithms. The datastore may also be leveraged forkey management in some embodiments that will be discussed in greaterdetail below.

Each of the algorithm developer 120a-x, and the data stewards 160a-y andthe core management system 140 may be coupled together by a network 130.In most cases the network is comprised of a cellular network and/or theinternet. However, it is envisioned that the network includes any widearea network (WAN) architecture, including private WAN’s, or privatelocal area networks (LANs) in conjunction with private or public WANs.

In this particular system, the data stewards maintain sequesteredcomputing nodes 110a-y which function to actually perform thecomputation of the algorithm on the dataset. The sequestered computingnodes, or “enclaves”, may be physically separate computer serversystems, or may encompass virtual machines operating within a greaternetwork of the data steward’s systems. The sequestered computing nodesshould be thought of as a vault. The encrypted algorithm and encrypteddatasets are supplied to the vault, which is then sealed. Encryptionkeys 390 unique to the vault are then provided, which allows thedecryption of the data and models to occur. No party has access to thevault at this time, and the algorithm is able to securely operate on thedata. The data and algorithms may then be destroyed, or maintained asencrypted, when the vault is “opened” in order to access thereport/output derived from the application of the algorithm on thedataset. Due to the specific sequestered computing node being requiredto decrypt the given algorithm(s) and data, there is no way they can beintercepted and decrypted. This system relies upon public-private keytechniques, where the algorithm developer utilizes the public key 390for encryption of the algorithm, and the sequestered computing nodeincludes the private key in order to perform the decryption. In someembodiments, the private key may be hardware (in the case of Azure, forexample) or software linked (in the case of AWS, for example).

In some particular embodiments, the system sends algorithm models via anAzure Confidential Computing environment to two data stewardenvironments. Upon verification, the model and the data entered theIntel SGX sequestered enclave where the model is able to be validatedagainst the protected information, for example PHI, data sets.Throughout the process, the algorithm owner cannot see the data, thedata steward cannot see the algorithm model, and the management core cansee neither the data nor the model.

The data steward uploads encrypted data to their cloud environment usingan encrypted connection that terminates inside an Intel SGX-sequesteredenclave. Then, the algorithm developer submits an encrypted,containerized AI model which also terminates into an IntelSGX-sequestered enclave. A key management system in the management coreenables the containers to authenticate and then run the model on thedata within the enclave. The data steward never sees the algorithminside the container and the data is never visible to the algorithmdeveloper. Neither component leaves the enclave. After the model runs,the developer receives a performance report on the values of thealgorithm’s performance along with a summary of the datacharacteristics. Finally, the algorithm owner may request that anencrypted artifact containing information about validation results isstored for regulatory compliance purposes and the data and the algorithmare wiped from the system.

FIG. 1B provides a similar ecosystem 100 b. This ecosystem also includesone or more algorithm developers 120a-x, which generate, encrypt andoutput their models. The core management system 140 receives theseencrypted payloads, and in some embodiments, transforms or augmentsunencrypted portions of the payloads. The major difference between thissubstantiation and the prior figure, is that the sequestered computingnode(s) 110a-y are present within a third party host 170a-y. An exampleof a third-party host may include an offsite server such as Amazon WebService (AWS) or similar cloud infrastructure. In such situations, thedata steward encrypts their dataset(s) and provides them, via thenetwork, to the third party hosted sequestered computing node(s) 110a-y.The output of the algorithm running on the dataset is then transferredfrom the sequestered computing node in the third-party, back via thenetwork to the data steward (or potentially some other recipient).

In some specific embodiments, the system relies on a unique combinationof software and hardware available through Azure Confidential Computing.The solution uses virtual machines (VMs) running on specialized Intelprocessors with Intel Software Guard Extension (SGX), in thisembodiment, running in the third party system. Intel SGX createssequestered portions of the hardware’s processor and memory known as“enclaves” making it impossible to view data or code inside the enclave.Software within the management core handles encryption, key management,and workflows.

In some embodiments, the system may be some hybrid between FIGS. 1A and1B. For example, some datasets may be processed at local sequesteredcomputing nodes, especially extremely large datasets, and others may beprocessed at third parties. Such systems provide flexibility based uponcomputational infrastructure, while still ensuring all data andalgorithms remain sequestered and not visible except to their respectiveowners.

Turning now to FIG. 2 , greater detail is provided regarding the coremanagement system 140. The core management system 140 may include a datascience development module 210, a data harmonizer workflow creationmodule 250, a software deployment module 230, a federated masteralgorithm training module 220, a system monitoring module 240, and adata store comprising global join data 240.

The data science development module 210 may be configured to receiveinput data requirements from the one or more algorithm developers forthe optimization and/or validation of the one or more models. The inputdata requirements define the objective for data curation, datatransformation, and data harmonization workflows. The input datarequirements also provide constraints for identifying data assetsacceptable for use with the one or more models. The data harmonizerworkflow creation module 250 may be configured to manage transformation,harmonization, and annotation protocol development and deployment. Thesoftware deployment module 230 may be configured along with the datascience development module 210 and the data harmonizer workflow creationmodule 250 to assess data assets for use with one or more models. Thisprocess can be automated or can be an interactive search/query process.The software deployment module 230 may be further configured along withthe data science development module 210 to integrate the models into asequestered capsule computing framework, along with required librariesand resources.

In some embodiments, it is desired to develop a robust, superioralgorithm/model that has learned from multiple disjoint private datasets (e.g., clinical and health data) collected by data hosts fromsources (e.g., patients). The federated master algorithm training modulemay be configured to aggregate the learning from the disjoint data setsinto a single master algorithm. In different embodiments, thealgorithmic methodology for the federated training may be different. Forexample, sharing of model parameters, ensemble learning, parent-teacherlearning on shared data and many other methods may be developed to allowfor federated training. The privacy and security requirements, alongwith commercial considerations such as the determination of how mucheach data system might be paid for access to data, may determine whichfederated training methodology is used.

The system monitoring module 240 monitors activity in sequesteredcomputing nodes. Monitored activity can range from operational trackingsuch as computing workload, error state, and connection status asexamples to data science monitoring such as amount of data processed,algorithm convergence status, variations in data characteristics, dataerrors, algorithm/model performance metrics, and a host of additionalmetrics, as required by each use case and embodiment.

In some instances, it is desirable to augment private data sets withadditional data located at the core management system (join data 150).For example, geolocation air quality data could be joined withgeolocation data of patients to ascertain environmental exposures. Incertain instances, join data may be transmitted to sequestered computingnodes to be joined with their proprietary datasets during dataharmonization or computation.

The sequestered computing nodes may include a harmonizer workflowmodule, harmonized data, a runtime server, a system monitoring module,and a data management module (not shown). The transformation,harmonization, and annotation workflows managed by the data harmonizerworkflow creation module may be deployed by and performed in theenvironment by harmonizer workflow module using transformations andharmonized data. In some instances, the join data may be transmitted tothe harmonizer workflow module to be joined with data during dataharmonization. The runtime server may be configured to run the privatedata sets through the algorithm/model.

The system monitoring module monitors activity in the sequesteredcomputing node. Monitored activity may include operational tracking suchas algorithm/model intake, workflow configuration, and data hostonboarding, as required by each use case and embodiment. The datamanagement module may be configured to import data assets such asprivate data sets while maintaining the data assets within thepre-exiting infrastructure of the data stewards.

Turning now to FIG. 3 , a first model of the flow of algorithms and dataare provided, generally at 300. The Zero-Trust Encryption System 320manages the encryption, by an encryption server 323, of all thealgorithm developer’s 120 software assets 321 in such a way as toprevent exposure of intellectual property (including source or objectcode) to any outside party, including the entity running the coremanagement system 140 and any affiliates, during storage, transmissionand runtime of said encrypted algorithms 325. In this embodiment, thealgorithm developer is responsible for encrypting the entire payload 325of the software using its own encryption keys. Decryption is only everallowed at runtime in a sequestered capsule computing environment 110.

The core management system 140 receives the encrypted computing assets(algorithms) 325 from the algorithm developer 120. Decryption keys tothese assets are not made available to the core management system 140 sothat sensitive materials are never visible to it. The core managementsystem 140 distributes these assets 325 to a multitude of data stewardnodes 160 where they can be processed further, in combination withprivate datasets, such as protected health information (PHI) 350.

Each Data Steward Node 160 maintains a sequestered computing node 110that is responsible for allowing the algorithm developer’s encryptedsoftware assets 325 to compute on a local private dataset 350 that isinitially encrypted. Within data steward node 160, one or more localprivate datasets (not illustrated) is harmonized, transformed, and/orannotated and then this dataset is encrypted by the data steward, into alocal dataset 350, for use inside the sequestered computing node 110.

The sequestered computing node 110 receives the encrypted softwareassets 325 and encrypted data steward dataset(s) 350 and manages theirdecryption in a way that prevents visibility to any data or code atruntime at the runtime server 330. In different embodiments this can beperformed using a variety of secure computing enclave technologies,including but not limited to hardware-based and software-basedisolation.

In this present embodiment, the entire algorithm developer softwareasset payload 325 is encrypted in a way that it can only be decrypted inan approved sequestered computing enclave/node 110. This approach worksfor sequestered enclave technologies that do not require modification ofsource code or runtime environments in order to secure the computingspace (e.g., software-based secure computing enclaves).

Turning to FIG. 4 , the general environment is maintained, as seengenerally at 400, however in this embodiment, the encryption server 323takes the algorithm asset 321, and only encrypts a specific sensitivelayer 425 (generally comprising the algorithm weights), while leavingremaining non-sensitive algorithm elements 420 (such as the containerand base model minus weights) unencrypted. This embodiment has theadvantage of allowing the unencrypted portion 420 of the payload to betransformed, or otherwise altered, by either the core management system140, or by the data steward 160. An example would be the conversion ofspecific library dependencies from the original operating system toEnclave OS, a special operating system that runs code in an Intel SGXsequestered computing enclave.

In a similar manner, FIG. 5 provides an example embodiment of a systemwhereby the sensitive and non-sensitive portions of the developer assets321 are treated differently, seen generally at 500. In this example,however, rather than only encrypting a specific layer of the ultimatepayload, the assets are separated into two portions: the sensitiveelements 525 and the non-sensitive elements 520. The non-sensitiveelements 520, are then transferred in the clear, while the sensitiveelements 525 are encrypted before leaving the zero trust encryptionsystem 320. As with the embodiment found in FIG. 4 , this methodology ofsplitting the payload into two entirely separate elements allows theunencrypted non-sensitive payload 520 to be modified.

Turning to FIG. 6 , one embodiment of the process for deployment andrunning of algorithms within the sequestered computing nodes isillustrated, at 600. Initially the algorithm developer provides thealgorithm to the system. The at least one algorithm/model is generatedby the algorithm developer using their own development environment,tools, and seed data sets (e.g., training/testing data sets). In someembodiments, the algorithms may be trained on external datasets instead,as will be discussed further below. The algorithm developer providesconstraints (at 610) for the optimization and/or validation of thealgorithm(s). Constraints may include any of the following: (i) trainingconstraints, (ii) data preparation constraints, and (iii) validationconstraints. These constraints define objectives for the optimizationand/or validation of the algorithm(s) including data preparation (e.g.,data curation, data transformation, data harmonization, and dataannotation), model training, model validation, and reporting.

In some embodiments, the training constraints may include, but are notlimited to, at least one of the following: hyperparameters,regularization criteria, convergence criteria, algorithm terminationcriteria, training/validation/test data splits defined for use inalgorithm(s), and training/testing report requirements. A model hyperparameter is a configuration that is external to the model, and whichvalue cannot be estimated from data. The hyperparameters are settingsthat may be tuned or optimized to control the behavior of a ML or AIalgorithm and help estimate or learn model parameters.

Regularization constrains the coefficient estimates towards zero. Thisdiscourages the learning of a more complex model in order to avoid therisk of overfitting. Regularization, significantly reduces the varianceof the model, without a substantial increase in its bias. Theconvergence criterion is used to verify the convergence of a sequence(e.g., the convergence of one or more weights after a number ofiterations). The algorithm termination criteria define parameters todetermine whether a model has achieved sufficient training. Becausealgorithm training is an iterative optimization process, the trainingalgorithm may perform the following steps multiple times. In general,termination criteria may include performance objectives for thealgorithm, typically defined as a minimum amount of performanceimprovement per iteration or set of iterations.

The training/testing report may include criteria that the algorithmdeveloper has an interest in observing from the training, optimization,and/or testing of the one or more models. In some instances, theconstraints for the metrics and criteria are selected to illustrate theperformance of the models. For example, the metrics and criteria such asmean percentage error may provide information on bias, variance, andother errors that may occur when finalizing a model such as vanishing orexploding gradients. Bias is an error in the learning algorithm. Whenthere is high bias, the learning algorithm is unable to learn relevantdetails in the data. Variance is an error in the learning algorithm,when the learning algorithm tries to over-learn from the dataset ortries to fit the training data as closely as possible. Further, commonerror metrics such as mean percentage error and R2 score are not alwaysindicative of accuracy of a model, and thus the algorithm developer maywant to define additional metrics and criteria for a more in depth lookat accuracy of the model.

Next, data assets that will be subjected to the algorithm(s) areidentified, acquired, and curated (at 620). FIG. 7A provides greaterdetail of this acquisition and curation of the data. Often, the data mayinclude healthcare related data (PHI). Initially, there is a query ifdata is present (at 710). The identification process may be performedautomatically by the platform running the queries for data assets (e.g.,running queries on the provisioned data stores using the data indices)using the input data requirements as the search terms and/or filters.Alternatively, this process may be performed using an interactiveprocess, for example, the algorithm developer may provide search termsand/or filters to the platform. The platform may formulate questions toobtain additional information, the algorithm developer may provide theadditional information, and the platform may run queries for the dataassets (e.g., running queries on databases of the one or more data hostsor web crawling to identify data hosts that may have data assets) usingthe search terms, filters, and/or additional information. In eitherinstance, the identifying is performed using differential privacy forsharing information within the data assets by describing patterns ofgroups within the data assets while withholding private informationabout individuals in the data assets.

If the assets are not available, the process generates a new datasteward node (at 720). The data query and onboarding activity(surrounded by a dotted line) is illustrated in this process flow ofacquiring the data; however, it should be realized that these steps maybe performed anytime prior to model and data encapsulation (step 650 inFIG. 6 ). Onboarding/creation of a new data steward node is shown ingreater detail in relation to FIG. 7B. In this example process a datahost compute and storage infrastructure (e.g., a sequestered computingnode as described with respect to FIGS. 1A-5 ) is provisioned (at 715)within the infrastructure of the data steward. In some instances, theprovisioning includes deployment of encapsulated algorithms in theinfrastructure, deployment of a physical computing device withappropriately provisioned hardware and software in the infrastructure,deployment of storage (physical data stores or cloud-based storage), ordeployment on public or private cloud infrastructure accessible via theinfrastructure, etc.

Next, governance and compliance requirements are performed (at 725). Insome instances, the governance and compliance requirements includesgetting clearance from an institutional review board, and/or review andapproval of compliance of any project being performed by the platformand/or the platform itself under governing law such as the HealthInsurance Portability and Accountability Act (HIPAA). Subsequently, thedata assets that the data steward desires to be made available foroptimization and/or validation of algorithm(s) are retrieved (at 735).In some instances, the data assets may be transferred from existingstorage locations and formats to provisioned storage (physical datastores or cloud-based storage) for use by the sequestered computing node(curated into one or more data stores). The data assets may then beobfuscated (at 745). Data obfuscation is a process that includes dataencryption or tokenization, as discussed in much greater detail below.Lastly, the data assets may be indexed (at 755). Data indexing allowsqueries to retrieve data from a database in an efficient manner. Theindexes may be related to specific tables and may be comprised of one ormore keys or values to be looked up in the index (e.g., the keys may bebased on a data table’s columns or rows).

Returning to FIG. 7A, after the creation of the new data steward, theproject may be configured (at 730). In some instances, the data stewardcomputer and storage infrastructure is configured to handle a newproject with the identified data assets. In some instances, theconfiguration is performed similarly to the process described of FIG.7B. Next, regulatory approvals (e.g., IRB and other data governanceprocesses) are completed and documented (at 740). Lastly, the new datais provisioned (at 750). In some instances, the data storageprovisioning includes identification and provisioning of a new logicaldata storage location, along with creation of an appropriate datastorage and query structure.

Returning now to FIG. 6 , after the data is acquired and configured, aquery is performed if there is a need for data annotation (at 630). Ifso, the data is initially harmonized (at 633) and then annotated (at635). Data harmonization is the process of collecting data sets ofdiffering file formats, naming conventions, and columns, andtransforming it into a cohesive data set. The annotation is performed bythe data steward in the sequestered computing node. A key principle tothe transformation and annotation processes is that the platformfacilitates a variety of processes to apply and refine data cleaning andtransformation algorithms, while preserving the privacy of the dataassets, all without requiring data to be moved outside of the technicalpurview of the data steward.

After annotation, or if annotation was not required, another querydetermines if additional data harmonization is needed (at 640). If so,then there is another harmonization step (at 645) that occurs in amanner similar to that disclosed above. After harmonization, or ifharmonization isn’t needed, the models and data are encapsulated (at650). Data and model encapsulation is described in greater detail inrelation to FIG. 8 . In the encapsulation process the protected data,and the algorithm are each encrypted (at 810 and 830 respectively). Insome embodiments, the data is encrypted either using traditionalencryption algorithms (e.g., RSA) or homomorphic encryption.

Next the encrypted data and encrypted algorithm are provided to thesequestered computing node (at 820 and 840 respectively). Thereprocesses of encryption and providing the encrypted payloads to thesequestered computing nodes may be performed asynchronously, or inparallel. Subsequently, the sequestered computing node may phone home tothe core management node (at 850) requesting the keys needed. These keysare then also supplied to the sequestered computing node (at 860),thereby allowing the decryption of the assets.

Returning again to FIG. 6 , once the assets are all within thesequestered computing node, they may be decrypted and the algorithm mayrun against the dataset (at 660). The results from such runtime may beoutputted as a report (at 670) for downstream consumption.

Turning now to FIG. 9 , a first embodiment of the system for zero-trustprocessing of the data assets by the algorithm is provided, at 900. Inthis example process, the algorithm is initially generated by thealgorithm developer (at 910) in a manner similar to that describedpreviously. The entire algorithm, including its container, is thenencrypted (at 920), using a public key, by the encryption server withinthe zero-trust system of the algorithm developer’s infrastructure. Theentire encrypted payload is provided to the core management system (at930). The core management system then distributes the encrypted payloadto the sequestered computing enclaves (at 940).

Likewise, the data steward collects the data assets desired forprocessing by the algorithm. This data is also provided to thesequestered computing node. In some embodiments, this data may also beencrypted. The sequestered computing node then contacts the coremanagement system for the keys. The system relies upon public-privatekey methodologies for the decryption of the algorithm, and possibly thedata (at 950).

After decryption within the sequestered computing node, the algorithm(s)are run (at 960) against the protected health information (or othersensitive information based upon the given use case). The results arethen output (at 970) to the appropriate downstream audience (generallythe data steward, but may include public health agencies or otherinterested parties).

FIG. 10 , on the other hand, provides another methodology of zero-trustcomputation that has the advantage of allowing some transformation ofthe algorithm data by either the core management system or the datasteward themselves, shown generally at 1000. As with the priorembodiment, the algorithm is initially generated by the algorithmdeveloper (at 1010). However, at this point the two methodologiesdiverge. Rather than encrypt the entire algorithm payload, itdifferentiates between the sensitive portions of the algorithm(generally the algorithm weights), and non-sensitive portions of thealgorithm (including the container, for example). The process thenencrypts only layers of the payload that have been flagged as sensitive(at 1020).

The partially encrypted payload is then transferred to the coremanagement system (at 1030). At this stage a determination is madewhether a modification is desired to the non-sensitive, non-encryptedportion of the payload (at 1040). If a modification is desired, then itmay be performed in a similar manner as discussed previously (at 1045).

If no modification is desired, or after the modification is performed,the payload may be transferred (at 1050) to the sequestered computingnode located within the data steward infrastructure (or a third party).Although not illustrated, there is again an opportunity at this stage tomodify any non-encrypted portions of the payload when the algorithmpayload is in the data steward’s possession.

Next, the keys unique to the sequestered computing node are employed todecrypt the sensitive layer of the payload (at 1060), and the algorithmsare run against the locally available protected health information (at1070). In the use case where a third party is hosting the sequesteredcomputing node, the protected health information may be encrypted at thedata steward before being transferred to the sequestered computing nodeat said third party. Regardless of sequestered computing node location,after runtime, the resulting report is outputted to the data stewardand/or other interested party (at 1080).

FIG. 11 , as seen at 1100, is similar to the prior two figures in manyregards. The algorithm is similarly generated at the algorithm developer(at 1110); however, rather than being subject to an encryption stepimmediately, the algorithm payload may be logically separated into asensitive portion and a non-sensitive portion (at 1120). To ensure thatthe algorithm runs properly when it is ultimately decrypted in the(sequestered) sequestered computing enclave, instructions about theorder in which computation steps are carried out may be added to theunencrypted portion of the payload.

Subsequently, the sensitive portion is encrypted at the zero-trustencryption system (at 1130), leaving the non-sensitive portion in theclear. Both the encrypted portion and the non-encrypted portion of thepayload are transferred to the core management system (at 1140). Thistransfer may be performed as a single payload, or may be doneasynchronously. Again, there is an opportunity at the core managementsystem to perform a modification of the non-sensitive portion of thepayload. A query is made if such a modification is desired (at 1150),and if so it is performed (at 1155). Transformations may be similar tothose detailed above.

Subsequently, the payload is provided to the sequestered computingnode(s) by the core management system (at 1160). Again, as the payloadenters the data steward node(s), it is possible to perform modificationsto the non-encrypted portion(s). Once in the sequestered computing node,the sensitive portion is decrypted (at 1170), the entire algorithmpayload is run (at 1180) against the data that has been provided to thesequestered computing node (either locally or supplied as an encrypteddata package). Lastly, the resulting report is outputted to the relevantentities (at 1190).

Any of the above modalities of operation provide the instant zero-trustarchitecture with the ability to process a data source with an algorithmwithout the ability for the algorithm developer to have access to thedata being processed, the data steward being unable to view thealgorithm being used, or the core management system from having accessto either the data or the algorithm. This uniquely provides each partythe peace of mind that their respective valuable assets are not at risk,and facilitates the ability to easily, and securely, process datasets.

Turning now to FIG. 12 , a system for zero-trust training of algorithmsis presented, generally at 1200. Traditionally, algorithm developersrequire training data to develop and refine their algorithms. Such datais generally not readily available to the algorithm developer due to thenature of how such data is collected, and due to regulatory hurdles. Assuch, the algorithm developers often need to rely upon other parties(data stewards) to train their algorithms. As with running an algorithm,training the algorithm introduces the potential to expose the algorithmand/or the datasets being used to train it.

In this example system, the nascent algorithm is provided to thesequestered computing node 110 in the data steward node 160. This new,untrained algorithm may be prepared by the algorithm developer (notshown) and provided in the clear to the sequestered computing node 110as it does not yet contain any sensitive data. The sequestered computingnode leverages the locally available protected health information 350,using a training server 1230, to train the algorithm. This generates asensitive portion of the algorithm 1225 (generally the weights andcoefficients of the algorithm), and a non-sensitive portion of thealgorithm 1220. As the training is performed within the sequesteredcomputing node 110, the data steward 160 does not have access to thealgorithm that is being trained. Once the algorithm is trained, thesensitive portion 1225 of the algorithm is encrypted prior to beingreleased from the sequestered computing enclave 110. This partiallyencrypted payload is then transferred to the data management core 140,and distributed to a sequestered capsule computing service 1250,operating within an enclave development node 1210. The enclavedevelopment node is generally hosted by one or more data stewards.

The sequestered capsule computing node 1250 operates in a similar manneras the sequestered computing node 110 in that once it is “locked” thereis no visibility into the inner workings of the sequestered capsulecomputing node 1250. As such, once the algorithm payload is received,the sequestered capsule computing node 1250 may decrypt the sensitiveportion of the algorithm 1225 using a public-private key methodology.The sequestered capsule computing node 1250 also has access tovalidation data 1255. The algorithm is run against the validation data,and the output is compared against a set of expected results. If theresults substantially match, it indicates that the algorithm is properlytrained, if the results do not match, then additional training may berequired.

FIG. 13 provides the process flow, at 1300, for this trainingmethodology. In the sequestered computing node, the algorithm isinitially trained (at 1310). The training assets (sensitive portions ofthe algorithm) are encrypted within the sequestered computing node (at1320). Subsequently the feature representations for the training dataare profiled (at 1330). One example of a profiling methodology would beto take the activations of the certain AI model layers for samples inboth the training and test set, and see if another model can be trainedto recognize which activations came from which dataset. These featurerepresentations are non-sensitive, and are thus not encrypted. Theprofile and the encrypted data assets are then output to the coremanagement system (at 1340) and are distributed to one or moresequestered capsule computing enclaves (at 1350). At the sequesteredcapsule computing node, the training assets are decrypted and validated(at 1360). After validation the training assets from more than one datasteward node are combined into a single featured training model (at1370). This is known as federated training.

Turning now to FIG. 14 , a semi-trust computing architecture isprovided, shown generally at 1300. Unlike a zero-trust system, in thisexample the core management system 140 operates not only as thedistributer of the algorithm payloads, but also acts as a key managementsystem. Thus, theoretically, the core management system 140 coulddecrypt the algorithm as it is provided. Thus, a certain level of trustis required between the algorithm developer 120 and the core managementsystem 140. As such, it may be advantageous, in some particularembodiments, to have the core management system be hosted by thealgorithm developer, or have the algorithm developer act as the keymanagement system directly.

Regardless, in the instant embodiment, the algorithm developer’salgorithm 321 is provided to the encryption server 323 to generate anencrypted payload 320. Here the entire payload is encrypted, however, aspreviously discussed, in alternate embodiments only a certain layer ofthe payload needs to be encrypted, or the payload may be separated intosensitive and non-sensitive portions and only specific portions aretherefore encrypted. Regardless of method employed, the payload isprovided to the core management system 140, which distributes thepayload to licensed computing nodes 1410. These local nodes may includelow processing powered devices that contain only local data sets.Examples of these local computing nodes may include devices such as EKGmachines, dialysis machines, and other peripheral medical devices.Outside of the medical field, devices may include ATMs, smart homeappliances, autonomous vehicles, or any other networked device thatincludes local datasets that need processing.

In addition to receiving the encrypted packet, the core managementsystem includes a key management server 1430, which provides a key tothe licensed computing node 1410 to decrypt the algorithm 320 andprocess local data 1420. In some embodiments, certain devices may bepre-provisioned with a key, thereby allowing the algorithm payload to bedistributed without the need for a key management server by the coremanagement system 140. This allows for deployment of the payload evenwhen the core management system 140 cannot be contacted directly toobtain decryption keys or to confirm license validity, for example ifthe local environment does not have a reliable Internet connection. Insome embodiments, license data may be stored on the blockchain to allowadditional computing models.

FIG. 15 , in turn, provides an example process for deploying and runningalgorithms on licensed computing nodes, shown generally at 1500. In thisexample process, the trained algorithm is first received/generated bythe algorithm developer (at 1510). This algorithm is encrypted in wholeor in part (at 1520) in the zero-trust encryption node. The payload isprovided to the core management system (at 1530), which then distributesit to one or more licensed computing nodes (at 1540). The key managementserver within the core management system provides the necessary keys tothe appropriate licensed computing node(s) (at 1550). The licensedcomputing node(s) leverage the keys to decrypt the payload (at 1560),and run the algorithm on locally available data (at 1570).

FIG. 16 provides an example diagram for the outputting of differentialreports based upon audience privileges is provided, shown generally at1600. In this example diagram, in a manner consistent with thepreviously described processing of datasets in a zero-trust environment,the algorithm developer 120 provides their algorithm 321 to anencryption server 323 within the zero-trust encryption system 320. Thisresults in an encrypted payload 325. While the entire payload isillustrated as being encrypted, consistent with the various described itis possible that only portions of the algorithm may be encrypted.However, for the sake of brevity and clarity, only embodiments where theentire algorithm payloads are encrypted are illustrated.

The encrypted payload 325 is provided to the core management system 140,which also manages keys 390. The core management system 140 is unable toaccess and decrypt the payload 325. The core management system 140manages the deployment of the payload to a proper data steward 160 forprocessing on their protected health information 350. The payload isprovided to a sequestered computing node 110 within the data steward.Only when the payload is within the sequestered computing node 110 is itable to be decrypted. The data steward 160 is unable to access assetswithin the sequestered computing node 110, therefore the algorithm canbe decrypted and used to process the protected information, for examplePHI, without the data steward being able to access the algorithm.

The runtime server 330 processes the protected health information 350using the decrypted algorithm, which is then purged from the sequesteredcomputing node 110 after completed. The result of the processing of theprotected information is output as exported data 1610, which is fullyidentifiable results. Additionally, obfuscated records 1620, which havethe identifying information, and any other protected in formation,hashed is provided back to the algorithm developer 120. These obfuscatedrecords 1620 are leveraged by the algorithm developer to validate thealgorithm operation. A mapping between original record ID and theobfuscated ID may be held by the data steward or other permittedstakeholder (e.g. a regulatory agency) so that significant results thathave been reported to the algorithm developer can be matched to actualrecords, enabling further action or inquiry to be undertaken.

Turning to FIG. 17 , the processing of datasets with multiple algorithmsis provided, shown generally at 1700. Similar to other disclosedsystems, the algorithms 321A and 321B are encrypted by their respectiveencryption servers 323A and 323B within their respective algorithmdeveloper’s 120A and 120B zero-encryption systems 320A and 320B,respectively. Again, in this example diagram the entire algorithms 321Aand 321B are shown as being encrypted 325A and 325B, respectively.However, it is within the scope of the disclosure that the alternateencryption techniques (portion encryption and bifurcation and segmentencryption) are considered.

The core management system 140 received the multiple encryptedalgorithms 235A and 325B. These algorithm packets are provided (again,in an encrypted and inaccessible format) to the data steward 160. Whenin the sequestered computing node 110, these algorithms may be decryptedand used by the runtime server 330 to process the protected healthinformation 350. In some embodiments, the protected information, forexample PHI, may be processed by the first algorithm 325A and inparallel by the second algorithm 325B. The results from these parallelprocessing may be compared to one another to validate findings, orotherwise achieve some computational advantage. For example, in manysituations the outputs of multiple algorithms can be combined to createa stronger statistical signal (and therefore more accurate or usefulresults) than any single algorithm. For example, the first algorithm mayprocess the protected information to yield a first result, and a secondmodel renders a second result. These results may be combined to classifythe results (e.g., a weighted sum of the algorithm results, or combiningclassification results independently). From a privacy and securityperspective, the ability to combine signals within a secure encapsulatedcomputing environment allows the creation of such ensemble resultswithout the requirement to publish the individual intermediate results.

In alternate systems, the protected information may be processed by thefirst algorithm 325A, and the output of this processing may be a newdataset for processing by the second algorithm 325B. This is aparticularly powerful technique in that the ability to share datasetsbetween the two algorithm developers, which is required in traditionalprocessing, requires a significant degree of trust between the parties(including significant contractual arrangements). This is particularlyproblematic in that the algorithm developers 120A and 120B arepotentially direct competitors.

The output of this serial processing of protected information allows forthe creation of advanced analytics pipelines on private data whileprotecting the intellectual property (IP) of all pipeline algorithmiccomponents. For cases in which the output of any of the componentalgorithms is restricted for reasons of IP protection or privacy, aserial pipeline computed entirely within an encapsulated computingenvironment is advantageous. For example, a first algorithm mightidentify individuals, objects, or activities within image data and asecond could compute on a combination of these outputs and other datawithin the enclave. It is easy to see that if the identities ofindividuals within these images needed to be protected, it would bepreferable to run this serial pipeline entirely within an enclave.

Turning now to FIG. 18 , another example process for complex processingof different protected information, for example PHI, datasets by variousalgorithms is provided, shown generally at 1800. As with FIG. 17 , thealgorithms 321A and 321B are encrypted by their respective encryptionservers 323A and 323B within their respective algorithm developers’ 120Aand 120B zero-encryption systems 320A and 320B, respectively. Again, inthis example diagram the entire algorithms 321A and 321B are shown asbeing encrypted 325A and 325B, respectively.

These encrypted algorithms 325A and 325B are sent to the core managementsystem 140 for routing to the proper data stewards. In this examplesystem, the first algorithm 325A is provided to a first data steward160A. The encrypted packet 325A is encapsulated in the sequesteredcomputing node 110A, which is then decrypted and used by the runtimeserver 330A to process the protected health information 350A belongingto this first data steward 160A. This processing generates an output1810. The output is encrypted within the data steward 160A environmentand is then sent to the core management system 140 for routing. As withthe algorithm payloads, these encrypted output reports 1810 areinaccessible to the core management system 140, therefore ensuringend-to-end protection of all sensitive data. This output data is thenprovided to the sequestered computing node 110B of a second data steward160B. The output data is able to be decrypted only within thesequestered computing node 110B thereby ensuring the content of theoutput 1810 is not accessible by the second data steward 160B.

Within the sequestered computing node 110B, the output data 1810 may beprocessed along with protected information 350B of the second datasteward 160B, using the runtime server 330B by the second algorithm325B. In some embodiment, the output data may alter the second set ofprotected information 350B (or vice versa), and this modified dataset isused by the algorithm 325B for generating a final output. In alternateembodiments, the second algorithm 325B may consume the output dataset1810 and the second set of protected health information 350Bindependently in order to generate a final output. The first methodologycould be used to extract features from unstructured data in a datasetand then combine those features with other data in the data set togenerate an output (for example a prediction or class determination).This type of pipeline is used often in healthcare applications in whichthe source data, such as clinical notes, are not necessarily representedin an ideal format for the second algorithm to operate on them. Thesecond methodology could be used to create an ensemble classifier frommultiple other algorithms, thus increasing the statistical strength ofthe output. This approach could also be used to simply compare theoutputs of two algorithms that are designed to answer the same question.

Turning now to FIG. 19 , the process of generating obfuscated recordsfor algorithm validation is provided, shown generally at 1900. In thisexample process an algorithm is encrypted at the location of thealgorithm developer (at 1910). Again, this encryption may be for theentire payload, or may only be for sensitive algorithm elements (weightsfor example). The encrypted payload is provided to the core managementsystem (at 1920), which then provides it to a sequestered enclave at adata steward (at 1930). Within the sequestered computing node, theencrypted payload is able to be decrypted, allowing the algorithm to beleveraged. The data steward also provides protected information to thesequestered enclave (at 1940).

The protected information is then processed by a runtime server usingthe algorithm (at 1950). This results in a new dataset being created (at1960). The dataset includes identifying information (and possibly othersensitive patient information). This identifiable dataset is thenexported, in its raw form, to the data steward (at 1970). However, thedataset may be additionally processed to generate an obfuscated record(at 1980). In this dataset, the identifying information is first hashed.Subsequently the entire record is encrypted for transfer of theobfuscated record back to the algorithm developer (at 1990). This recordcan be decrypted at the algorithm developer, however, the hashedidentification information is unable to be accessed by the algorithmdeveloper. The obfuscated record may be used by the algorithm developerto validate the algorithm, or for other analytics.

FIG. 20 illustrates an example process for multi-algorithm processing ofprotected information within a single data steward, shown generally at2000. As with other embodiments, the first steps of this processincludes the encryption of algorithms at the first and second algorithmdevelopers (at 2010 and 2020, respectively). These encrypted algorithmsare provided to the core management system, which then provides bothalgorithms to a single data steward, and in particular to thesequestered computing node where the encrypted algorithms are able to bedecrypted (at 2030).

The data steward also provides the protected information in their careto the sequestered enclave (at 2040). This protected information is thenprocessed (at 2050) by both algorithms, either individually in parallel,or as a serial processing, where the output of one algorithm’sprocessing is the input into the second algorithm.

Turning to FIG. 21 , an example process for multi algorithm on multipledatasets are provided, shown generally at 2100. In this example processa first algorithm is initially developed and then encrypted by analgorithm developer (at 2105). The encrypted algorithm is provided tothe AI core management system (at 2110), which is then provided to afirst data steward’s sequestered enclave (at 2115).

The data steward provides their protected information to the sequesteredcomputing node as well (at 2120). Once the algorithm is decrypted, thealgorithms may process the protected information that is made availablefrom the data steward (at 2125). This processing results in thegeneration of a first output. This output has identifiable informationas well as report results. The identifiable information may be hashed,and subsequently the entire output is encrypted. The encrypted output issent to the core management system (at 2130) and then subsequentlyrouted to a second sequestered enclave that is present at a second datasteward (at 2135).

A second algorithm, generated by a second algorithm developer andencrypted, is then transferred to this second sequestered enclave viathe core management system (at 2140). Protected health information ofthis second data steward is also provided to the secured enclave (at2145). At this stage, the sequestered computing node has access to thesecond algorithm, protected information from the second data steward,and the output of the first algorithm working upon the protectedinformation from the first data steward. This second algorithm is thendecrypted, and used to process both the output and the second set ofprotected information (at 2150). This results in the generation of asecond output (at 2155) which may provide new insights that areunavailable from any one set of protected information.

Turning now to FIG. 22 , a system for matching outputs between differingprocessed protected information is disclosed, shown generally at 2200.In this example process, an algorithm is used to process the protectedinformation of a first data steward in any manner previously disclosed(at 2210). The identifying N-fields of the processed dataset are thennormalized, and then hashed (at 2220). The identifying information isgenerally a set of fields, each field containing a different identifier.For example, there may be fields for birthdate, name, social securitynumber, weight, height, Medical Record Number (MRN), patient ID, and thelike. Normalization may depend upon the field. For example, birthdatemay be placed in a specific format, such as MM/DD/YYYY. Likewise, MRNmay have all characters lowercased, and all spaces removed from thetoken string, for example.

Once all the fields are normalized, the hash is generated by encryptingthese identifying fields, and then the entire payload is also encrypted(at 2230) so that anyone intercepting the output is unable to access thedata contained therein. The encrypted payload is then transferred, viathe core management system, to a second sequestered computing node (at2250). A second dataset is calculated within the second enclave (at2250). This may include the same algorithm operating on a differentprotected information (for example PHI) dataset, or an entirelydifferent algorithm operating on the same or different protectedinformation dataset. Regardless, the output from this second operationmay also have the identifier fields hashed (at 2260) to prevent othersfrom having access to the sensitive identification data.

The next step is to match records by individual between the firstoutputted dataset and the second outputted dataset (at 2270). There areat least two methods disclosed herein to enable matching of datasethashes, as will be discussed in relation to FIGS. 23A and 23B,respectively. After the hashes are matched, the individual candidatescan be identified (at 2280). This method allows the serial applicationof complementary algorithms on distinct, private datasets, neither ofwhich is visible to the one or more algorithm owners, applied at to thematched records. The applications of this are numerous: For example, aninsurance company’s data might be processed by a first algorithm tocreate a vector of features for each patient in the data set (diagnoses,history of procedures, costs, etc.). This data set might be indexed by apatient ID (ID-A) that is unique to the payor and can’t be directlymatched with patient IDs in other datasets. This ID-A would be encrypted(distance preserving hash, homomorphic encrypted, etc.) along with theoutput vector. A second algorithm would operate on a second data set,for example from a healthcare provider system, combining the firstresults with the second data set to generate a new result set. In someembodiments, the hashes might be matched before the second computationis performed. In other embodiments, the two sets of data vectors arecombined as an outer product (possible reduced in size by partialmatching). All possible results are tabulated and the reduction tocorrectly matched patient records is performed outside the enclave. (Itis recognized that an outer multiplication might result in a largeresultant dataset, but there are many applications in which this wouldnot be a significant constraint). This pattern would also apply to abanking use case in which features from one or more transactions in oneor more banks are extracted by a first algorithm , and combined with aregulator’s, or other central watchdog’s, data to compute with a secondalgorithm to detect fraudulent or suspicious transactions.

Turning now to FIGS. 23A and 23B, two methods for matching individualidentifying hashes are provided, shown generally at 2270A and 2270Brespectively. As the identifying information is hashed by each datasteward, the other party cannot disambiguate the data in order to linkup output results contained in the report with any given patient. Assuch, data can be more readily transferred without the need forextensive confidentiality agreements and protections. However, there isgreat value in being able to link up records, as exemplified above.

In FIG. 23A, the identifier information fields on a training set of dataare normalized (at 2310), in the same manner as previously described.This allows for training of a deep neural network AI model (at 2320).This model generally provides a binary output on if two normalized setsof hashed data are the same or not. In such a model the last layer isgenerally a linear classifier. The output from the layer just before thelinear classifier may be leveraged in this process. This output is a setof feature vectors. These feature vectors generated from the modeloperating on a hash of identifiers is selected for each output dataset(at 2330). Any two-feature vector sets from one dataset compared to theother dataset are then compared, and the degree of distance between theangle of the vectors is calculated (at 2340). This degree of angledistance indicates how closely the two hashes are toward one another.Therefore, if the cosine angle distance between the two vectors is belowa preconfigured threshold, the system may determine there is a matchbetween the two given hashes (at 2350). The preconfigured threshold maybe modified or computed based on the desired properties of the output(for example, an application intended to find the most complete list ofcandidates for a therapy might tolerate more false positives andtherefore use a lower threshold, while a public health screeningstrategy would desire to minimize costs by using a higher threshold withfewer false positives, but potentially missing some true positives).

In contrast, the method of FIG. 23B relies upon homomorphic encryption.In this example process, the N identification fields of the given recordare homomorphically encrypted (at 2305). A machine learning model isthen trained using a noisy dataset (e.g., a dataset with erroneous andmissing fields of data) to compare and identify matching homomorphicallyencrypted hashes (at 2315). After being fully trained, the model may beused to match the hashes of one dataset to those of a second dataset (at2325).

Regardless of method employed, the ability to match individual patientswithin two datasets allows different data stewards to combine, compareand contrast their processed data without revealing to any other partythe identity of their patients. This allows compliance with regulations,such as HIPAA, while allowing for unprecedented analytics with disparateparties.

Moving forward, all of the above systems and methods of zero-trustcomputing are only as useful as the data sets and algorithms beingemployed. In this kind of data processing, the old adage of “garbage-in,garbage-out” is entirely accurate. As such, there is a strong need forthe ability to verify and validate both the data being employed, and thealgorithm operation. To this end, the core management system maygenerate a host of tools that address these very concerns. The coremanagement system may then disseminate these tools to the data stewards160 for employing. Technically, by introducing tooling from anotherparty into the data steward’s system, there is a level of trust requiredbetween the core management system and the data steward. As such, whenthese tools are employed, the system isn’t technically “zero-trust” butrather an extremely limited trust system. However, for thefunctionalities these tools provide a data steward, this level of trustis typically warranted. After all, and software that touches the datasets (such as the database management software) is a potential risk(albeit minimal).

FIG. 24A provides a block diagram for the system for creation of a“synthetic data steward” with the ability to combine data from differentsources longitudinally (e.g., a single record in the computation by thealgorithm being constructed from data originating from multiple datasources) as a final data set. Unlike other systems disclosed already,this example system relaxes the constraint that the sensitive data 2435a-b never leaves the infrastructure of a given data steward 160A-B.However, all other security constraints remain intact. This includes thefact that the sensitive data 2435 a-b is never ‘seen’ by anycounterparty, that the algorithm 325 is never ‘seen’ by any othercounterparty, and that the sensitive data 2435 a-b does not need to bede-identified or otherwise modified before computations are performed onit. By ‘seen’ it means that any of the underlying data/code is availableto the party in-the-clear as opposed to in an encrypted state.

In this example system, the algorithm developer 120 generates analgorithm 325 which is then encrypted and shared with the coremanagement system 140. This package remains encrypted and is provided tothe synthetic data steward node 2415. Each data steward node 160A-Bcontributes a different portion of the sensitive data required by thealgorithm developer’s 120 data specification. This specificationoutlines the kinds/quality/amount of data required for the algorithm 325to operate successfully. The union of the data from the various datastewards 160A-B satisfies this specification requirement, therebyallowing the algorithm 325 to successfully operate on the amalgamateddata set (seen as the conjoined 2435 a and 2435 b dataset within thesequestered computing service 2425) located in the synthetic datasteward node 2415. It should be noted that two data stewards 160A and160B are illustrated in this example figure. In reality, any number ofdata stewards 160A-B may be providing sensitive data 2435 a-b to thesynthetic data steward node 2415 for generating an amalgamated finaldata set.

Sensitive data 2435 a-b that is shared with the synthetic data stewardnode 2415 may be subject to any manner of transforms in order to get thedata into a standardized format prior to operation with the algorithm325. A secure computing enclave known as the sequestered computingservice 2425 operating within the synthetic data steward node 2415 isable to decrypt the algorithm 325, and the individual data sets 2435a-b, and allows the operation of the algorithm 325 on this amalgamatedfinal data set to generate a consolidated output. This output may thenbe encrypted, when desired, and shared with any number of stakeholders.These stakeholders may include the algorithm developer 120, the datasteward(s) 160A-B, regulatory bodies, researchers, and the like.

Turning to FIG. 24B, a more detailed illustration of the operation ofthe synthetic data steward node 2415. The synthetic data steward node2415 orchestrates the assembly of input data from the multiple datasteward nodes 160A-B using a data assembly module 2445. The dataassembly module 2445 assembles/combines the data from the multiple datasteward nodes 160A-B using any number of matching methodologies. In someembodiments when one or more keys can be used to match records fromdifferent sources, the matching methodology is to create a single finaldata set (seen as the consolidated data stack in the sequesteredcomputing service 2425) for all of the keys for which a complete recordis available. In some cases, records from one data steward (e.g., datasteward 160A) may not be present in another (e.g., data steward 160B).Such records will not be included in the final data set, but statisticsabout their presence or absence in each source data set may be noted forquality purposes (for example to ensure that record mismatches do notcause bias in the final data set).

In other embodiments, when unique keys are not available, then a recordmatching algorithm may be employed by the data assembly module 2445. Forexample, depending upon the type of data being computed upon, matchingmight be performed using demographic data for individuals represented ineach record of a healthcare data set, or transaction types andcounterparty characteristics might be used for matching relatedfinancial transactions in a banking or regulatory application. There isan unlimited number of potential matching methodologies which could beemployed at data assembly module 2445. As in the case when keys areavailable, statistics about the presence or absence of records in eachsource may be noted. When record matching is required, information aboutthe strength or confidence of the match within each record may also beincluded in the data to allow different types of inference on the data,depending on how likely a matching error may have occurred.

FIG. 24C provides an example block diagram of the tooling that ispresent within the data steward 160. This tooling falls into five maincategories of functional operation. These systems work in concert to 1)validate the data being used, 2) when needed, transform the data into ausable dataset, 3) obscure the algorithm inputs to protect thealgorithm, 4) generate synthetic data to verify algorithm operability,and lastly 5) downstream analysis of the annotations of the data toensure that the outputs are being utilized correctly and consistently.

To this end, a data transformer 2410 provides the function of alteringthe datasets when errors are identified. The validator (or fidelimeter)2420 is leveraged to determine when said errors in the data are present,and when the data is sufficiently curated for consumption by thealgorithm.

The obfuscator 2430 obscures the required inputs to the algorithm. Thisprevents the data steward from processing very large amounts of data,and using the outputs in conjunction with the known inputs to reverseengineer the algorithm itself. The synthetic data generator 2440 makesnew datasets that allows the various parties to independently processthe datasets, without violating any HIPPA regulations. By having acommon input to work with, the outputs of the algorithm should matchregardless of which party is processing the data. This ensures the datasteward that the algorithm deployed in their enclave is operating asintended. Lastly, the output of any analysis is often provided todownstream annotators. These annotations are used to identify thepathologies, verify study results, and for other clinically significantoperations. The accuracy, and consistency of these annotations is ofcritical importance. The data annotation tooling 2450 ensures that theannotation process is operating as desired.

FIG. 25 provides a more detailed illustration of one of the more complextools: the data transformer 2410. The data transformer 2410 includes adata range and type matcher 2510, which determines what type of data isbeing analyzed, and applies domain specific analysis of outliers, rangeexpectations and cleaning tools. A distribution matcher 2520 is similarto the data range and type matcher in that it is a domain specificanalysis of the data distribution as compared to expected distributions.A time series tracker 2530 identifies data that is collected over atimeline and identifies trends and expectations in the data series.Although not shown, a data cross referencer identifies data fields thatare correlated and determines if the data reflects these correlations.For example, a blood neutrophil count should be correlated with totalwhite blood cell counts. A neutrophil count larger than the total countwould signify an error in the data, and a ratio outside an expectedboundary would either indicate a pathology or may signify corrupt data.

After the different analysis has been performed, a set of suggestedtransforms may be identified. A data modifier 2540 may serially applythe identified transforms, starting with the most basic. Alternatively,the data modifier may apply all transforms in parallel, generatingmultiple outputs (one from each transform). These outputs may be eachvalidated, and if a given output passes the validation, this transformis selected for usage.

Rather than these methods of traditional transform identification andapplication, a machine learned algorithm may be applied upon the dataset. A ML transformer 2550 may then apply the transform identified bythe ML algorithm. To achieve this, a machine learning algorithm would betrained on large sets of healthcare or other domain-specific data thathave been transformed with known transformations. This training processwould result in an algorithm that infers what transformation could beapplied to make source data match an exemplar. This effectivelyautomates the process of transforming data from original data stewarddata to the format expected by the algorithm, as defined by the dataprofile.

In some embodiments the traditional transform identification may run inparallel with the machine learning based identification, and whencommonality of transforms are identified then the transform may beautomatically applied. In most cases however, any transform may beprovided to a human for approval (or at least review). A humaninterfacer 2560 may be employed to present the input data, describe theappropriate transform, and illustrate the output results.

Now that the basic system modules have been described, the processes forthe transform of data, data obfuscation, synthetic data generation foralgorithm validation, and annotation validations will all be describedin greater detail. The first process to be discussed is the transform ofinput data, as seen in FIG. 26 at 2600. The process starts by taking inthe data (at 2610). Generally, data injection may include somepreprocessing steps, such as rotation and cropping of images, separationof data fields, and the like. Data injection may also include thenormalization of data and cleansing of basic errors (such as negativenumbers).

The ingested data is then subjected to a validation (at 2640).Validation includes identification of the type of data being validated.For example, a column (field) of data typically includes a headeridentifying the data type. The validation may utilize a dictionary ofkeywords and abbreviations in the detection of the data types, in someembodiments. After the data type is identified, a lookup of the type ofdata against expected values is performed. The expected values include arange of possible values, and a distribution element. The data to bevalidated is compared against the range values, and if the data includesa statistically appreciable number of entries that are outside therange, the validation may fail. Under a statistically relevant number ofdata points outside the range values may be attributed to dirty data(errors in the data) or extreme outliers. These values should be flaggedfor manual review, or deleted from the dataset. Over the statisticallyappreciable level of data points outside the range limits indicates thatthe data set is erroneous as a whole, and requires transformation. Theterm “statistically relevant” or “statistically appreciable” may be aconfigurable value, but typically ranges from between 1-10% of the datapoints. Most commonly the value ranges from 1-5%.

A good example of this validation failure is for a temperature field.Temperature of the data set should be in degrees Celsius. Allowableranges of temperature measurements for humans is between 35 and 38degrees. At these temperatures the person can exhibit hypothermia orconversely a fever, but these are “acceptable” temperatures.Temperatures outside these ranges suggest extreme outliers, andgenerally would indicate the person is in mortal danger. Thus, if a dataset includes numbers like 98.6, for example, the data would fail thevalidation.

Similarly, the distribution of the data may be compared against thevalues expected for the data type. For normal patients, a temperaturedistribution would be a narrow bell curve shape. For a dataset ofpatients with a known pathology, the curve may be skewed to reflect afever state in many patients. These expected curves are compared againstthe actual data set, and distributions that are not a good match may beflagged as suspect and cause a validation failure. Comparison of thecurves may be performed by least means squared, Procrustes distance, orFrechet distance methodologies. A configurable threshold for thedistance between the curves may be employed to determine when the curveis “not a good match” and therefore fails the validation.

If the data does not pass validation (at 2650) the transforms requiredto modify the data are next identified (at 2620). There are multipleways to perform this identification step, as illustrated in FIGS. 27Aand 27B respectively. In FIG. 27A, ta 2620A, the fields to betransformed are compared to the domains (at 2710) very much like whenperforming the validation step. Domain is generally determined bycomparing headers, metadata, or other signifiers to the kind of dataemployed. The data is then cleansed (at 2720) if it has not already beenperformed during the data ingestion stage. Data cleansing may includeremoval of data fields that are blank, or impossible, for example. Next,a range based identification (at 2730) may be employed to identifyappropriate transforms. Going back to the body temperature example, oneof the known transforms for this domain is the conversion of Fahrenheitto Celsius. If the range of the input data is between 90-110, forexample, this transform is identified and employed. Another examplecould be the dosing units for medication administration: A sourcedataset might represent the amount of a drug administered to a patientin milliliters, grams, or IU, etc. while the data expected by thealgorithm is in mg, for example. The range of values in a medicationadministration field can be used to infer which units are being used ineach data set, and how to transform (translate) between them.

If a transform is thus identified for application (at 2740) thetransform may be identified and output for downstream processing. If norange based transform is found, a distribution based identification mayalternatively be employed (at 2750). Again, the distribution basedtransform identification is domain specific- there are known transformsexisting for the given domain (type of data being processed). If suchtransforms causes the actual data’s distribution to come in line withthe expected distribution, then is can be identified for application (at2760) and output for downstream processing. However, if no transformsare identified by the range or the distribution methods, there is afailure (at 2780) of the traditional transform identification, and othermethods must be utilized.

FIG. 27B is one such alternative means of transform identification,shown generally at 2620B. Again the transforms contemplated by the MLmodel are best identified when taken in light of the domain in whichthat data is operating (based upon data type/kind). As such the datafields are compared to a dictionary of known field types, and the kindof data is determined. This is used to select from all known transformsonly the ones which are generally applicable to the given domain (at2715). The data is again cleansed (at 2725) if it has not already beenperformed. A machine learning algorithm then consumes the input data (at2735). Different ML algorithms are utilized, each algorithm trained upondata within the specific domain contemplated. The ML model identifies ifa transform exists (at 2745) which would convert the input data into aformat/set of values that will pass validation. If so, the identifiedtransform is output for downstream analysis (at 2755). Otherwise, thereis a failure of the ML transform identification methodology (at 2765).

In some embodiments, the traditional transform identification is firstapplied, and if there is a failure, then the ML based transformidentification is attempted. This is because the ML identificationrequires significantly more processing power to complete. However, whenthere is ample processing power, these two methodologies may be employedin parallel, and the results compared to further validate the correcttransform. In yet other embodiments, only one transform identificationtechnique may be employed. For example, a system where the transformtool has recently been deployed may not have had sufficient dataprocessed in order to properly train the ML models. In such a situation,traditional transform identification and human inputted transforms maybe employed exclusively. However, for very sophisticated parties, whichhave exhaustively trained their models, a ML based transformidentification may be sufficient (or even preferred over dualidentification).

Returning to FIG. 26 , regardless of the methodology/ies employed toidentify the transform, after said identification the transform mayactually be applied (at 2630), and the process returns to a validationstage. In this manner the process is iterative, with each cycle the datais improved until it passes validation. Although not shown, it ispossible, however, for the transform identification to become exhaustedwithout the data being able to pass the validation stage. In suchinstances, a human operator is usually tasked with manual review of thedata to determine if there is a solution, or if the data is so corruptedas to be unusable.

If the data passes validation (at 2650) the process next determines ifhuman review is required (at 2660). Generally, if there is a transformperformed, human review will be desired. If so, human review with thetransforms that have been applied/suggested are highlighted to the user(at 2670). The human can accept or reject the proposed transforms.Alternately, the human can provide input into other transforms to beapplied. Regardless of if a human is involved or not, the final step ofthe process is to output (at 2680) the validated data for analysis bythe algorithm(s).

FIGS. 28A and 28B, in contrast, provides an example method for dataobfuscation for the protection of algorithm developers. In the firstmethod, shown generally at 2800A, data is obfuscated by requestingadditional data fields as they are available. The need for obfuscationis due to the fact that an algorithm can be reverse engineered. When theinput data is known, and sufficient quantities of it have been consumedby the algorithm, the output data may be utilized to determine how thealgorithm works. As many data stewards are processing vast quantities ofinput data, an algorithm developer’s concerns of the data steward’sability to reverse engineer their algorithm are very real. And aspreviously mentioned, the IP involved in the algorithm may constitutethe vast majority of the value for the algorithm developer. One mannerof protecting the algorithm from reverse engineering is to eitherobfuscate the input or the output of the algorithm. However, obfuscatingthe output is undesirable, as it defeats the purpose of running thealgorithm in the first place. As such, data obfuscation of the inputdata is the best option to protect the algorithm developer.

The data available to the data steward is first ingested (at 2810). Whatis known as “low intensity” fields of data are identified by thealgorithm developer (at 2820). Low intensity fields are those that areeither 1) routinely collected anyway, or 2) can be collected withminimal effort. Blood pressure, for example, would constitute a “lowintensity” field. The algorithm developer also requests the data stewardto provide a listing of all available data types (at 2830). This requestisn’t for actual data; no PHI ever leaves the data steward. Instead, thealgorithm developer gets a listing of available data types. Theavailable data is compared against the low intensity data types (at2840). This identifies which fields are low intensity, but not readilyavailable. All fields with complete data are selected (at 2850) and adetermination is made if these fields are enough to obfuscate the inputs(at 2860). Sufficiency of fields for obfuscation may be determined bynumber of fields beyond the necessary fields. For example, assume analgorithm requires 6 data inputs to perform its analysis. In order to beproperly obfuscated it may be determined that 10 fields of data shouldbe requested. If the available data includes 11 fields, there may besufficient number of fields for obfuscation. However, if there are only8 fields available, there may be a need to collect further information.The exact number of fields needed to properly obfuscate the input datamay be a configurable number above the needed field number (in the aboveexample there was a need for 4 fields above the number of “real” fieldsrequired by the algorithm). Alternatively, the required number of fieldsmay be dependent upon the needed fields (such as some proportion of theactual number of fields consumed by the algorithm).

If a sufficient number of fields do already exist, the algorithmlibraries may be fashioned to require the available fields as inputs.However, if there is insufficient fields already available, thealgorithm developer may request (at 2870) the data steward to collectlow intensity fields (not already found in the available data). Thereason ‘low intensity’ fields are requested is that this places anadditional burden upon the data steward. Too much additional data, ordata that is difficult to collect, may deter the data steward fromwanting to utilize the algorithm entirely. As such, to balance the needfor algorithm protection, with the additional hurdle for the datasteward to use the algorithm, the easiest data types that can becollected (or even better, that have already been collected but notsupplied earlier) are requested. The data for these added ‘lowintensity’ fields are then added by the data steward to telmerize theavailable data (at 2880). Again, the data steward uses the fields thathave been selected/output (at 2890) to build their algorithm librariesto consume. Thus, when the data stewards run the algorithm, the fieldsof data requested include the ‘real’ fields needed by the algorithm, aswell as ‘dummy’ fields that prevent reverse engineering of thealgorithm.

In FIG. 28B, an alternate means for data obscuration is provided, at2800B. Initially the data is digested (at 2815) in a similar manner asdiscussed above. Then low intensity data fields are again identified (at2825). The low intensity fields are combined with the required fields(at 2835) to yield a set of fields that, if requested, may obfuscate thealgorithm developer’s IP. A check is made to determine if the number offields that exist between the required and low intensity fields issufficient to obfuscate the algorithm (at 2845). If not, additional“medium intensity” fields are identified and requested (at 2855). Mediumintensity fields are also routinely collected and/or are relativelyeasily collected information yet are less easily accessible than the“low intensity” fields. An example of a low intensity field is bloodpressure, for example. A medium intensity field would be blood glucoselevels (which are collected on a less frequent basis).

Regardless of if medium intensity fields are incorporated or not, thedata requested is appended to include the extra data fields, known asdata telemerization (at 2865) and the set of fields is requested fromthe data steward. The collected data fields are then output for thealgorithm to consume, and therefore obscures the algorithm’s inputs.

Turning now to FIG. 29 , a process for algorithm validation, leveragingsynthetic data, is provided at 2900. There are three main methodologiesfor the generation of the synthetic data, which may be performedindividually or together. The first requires the ingestion of actualdata (at 2910). Data may be cleaned of obvious errors, and if needed thedata validation and transformation of FIG. 26 may be employed to get thedata in condition for utilization. The data may then be deidentifiedand/or determined to be publicly consumable (at 2920). This data is nottechnically “synthetic”, but is a gold standard for utilization whenavailable.

However, most often the PHI is not able to be ‘deidentified’ and isprotected in a way that it cannot be made available to the public. Inorder to address this situation, a ML model may be trained upon the realdata, within the protected enclave (at 2930). To generate synthetic datathe ML model, once sufficiently trained can generate synthetic data (at2940). There are a number of mathematical techniques that can be used togenerate synthetic data. For example, it is possible to model data usinggenerative AI algorithms (e.g. GANs), traditional statisticaldistribution estimation, multivariate gaussian distribution estimation,Bayes networks, and many other data modeling techniques. Thedistributions of the data are validated after generation, and whennecessary the synthetic data is modified to pass these validations,resulting in knowledge about how the original data must be transformedto work with the algorithm.

The third manner of generating synthetic data is to take the ingesteddata and modify it using pseudo-random deviations (at 2905). Thepseudo-random deviations must all stay within an acceptable range basedupon the domain (type) of data being processed. For example, for bloodpressure, deviations of up to 10 may be entirely acceptable, but fortemperature, deviations of half a degree may be utilized. Regardless,the deviations must, in aggregate, form a distribution that mirrors thedistribution curve of the actual data. This ensures that the finalsynthetic data mimics actual data very closely.

Regardless of the three ways the data may be generated, it is thendistributed to all parties interested in the algorithm validation (at2950). At a minimum this generally includes the data steward and thealgorithm developer, but may include other entities, such as other datastewards, researcher, pharmaceutical or biotechnology companies, or anyparty with an interest in the algorithm’s performance. The algorithm maythen be run, on the identical synthetic data, across each individualparties’ platforms (at 2960). The resulting output may then be comparedacross each of the parties (at 2970). The outputs should be identical,thereby validating the algorithm performance. If there is a deviation inthe outputs, there is an error that needs be addressed.

Lastly, FIG. 30 provides an example process diagram for the validationof annotations, shown generally at 3000. There are three mainmethodologies for validating the annotation accuracy and consistency.These include salting datasets with known cases (at 3010). Theannotations from these salted datasets are then collected (at 3020) andcompared to the known correct annotations (at 3030). This method,already utilized extensively, is a very good indicator of the accuracyand consistency of individual annotators. However, this method requiresextensive redundancy in annotations, which is costly.

The second method employed is to apply a ML model that detectsdifferences between annotation in different datasets and data stewards(at 3025) This method does not reveal detailed accuracy measurements forspecific annotators, but rather identifies trends in the datasets anddata stewards. For example, an algorithm trained to predict theannotations in one data set can used on a dataset annotated in adifferent site to identify deviations in annotation from site to site(or annotator group to annotator group), as higher than expecteddifferences between actual and predicted annotations can indicatevariations in annotation quality or differences in how an annotationprotocol is being applied. Other modeling techniques that computecharacteristics of the annotations (statistical moments and otherquantitative features) can also be used to detect systematic differencesin annotation performance from site to site.

Lastly, the results between annotators may be directly compared (at3015). When the annotators each have redundancy in their annotations,the differences can be noted, and with sufficient redundancy, thecorrect annotation can be ascertained, and the accuracy for theindividual annotators can likewise be determined. Again, however, thistechnique requires more extensive resources, and is prohibitivelyexpensive in many cases.

Regardless of method employed to characterize the annotations, theconsistency and accuracy may be reported out (at 3050), and if neededcorrective actions may be employed. This could include additionaltraining for the annotators, cross training of annotators at differentdata stewards, or even the addition of ML annotation tools to assist inthe annotation process.

Now that the systems and methods for zero-trust computing, datavalidation and transform, data obfuscation, algorithm validation andannotator characterization have been provided, attention shall now befocused upon apparatuses capable of executing the above functions inreal-time. To facilitate this discussion, FIGS. 31A and 31B illustrate aComputer System 3100, which is suitable for implementing embodiments ofthe present invention. FIG. 31A shows one possible physical form of theComputer System 3100. Of course, the Computer System 3100 may have manyphysical forms ranging from a printed circuit board, an integratedcircuit, and a small handheld device up to a huge supercomputer.Computer system 3100 may include a Monitor 3102, a Display 3104, aHousing 3106, server blades including one or more storage Drives 3108, aKeyboard 3110, and a Mouse 3112. Medium 3114 is a computer-readablemedium used to transfer data to and from Computer System 3100.

FIG. 31B is an example of a block diagram for Computer System 3100.Attached to System Bus 3120 are a wide variety of subsystems.Processor(s) 3122 (also referred to as central processing units, orCPUs) are coupled to storage devices, including Memory 3124. Memory 3124includes random access memory (RAM) and read-only memory (ROM). As iswell known in the art, ROM acts to transfer data and instructionsuni-directionally to the CPU and RAM is used typically to transfer dataand instructions in a bi-directional manner. Both of these types ofmemories may include any suitable form of the computer-readable mediadescribed below. A Fixed Medium 3126 may also be coupledbi-directionally to the Processor 3122; it provides additional datastorage capacity and may also include any of the computer-readable mediadescribed below. Fixed Medium 3126 may be used to store programs, data,and the like and is typically a secondary storage medium (such as a harddisk) that is slower than primary storage. It will be appreciated thatthe information retained within Fixed Medium 3126 may, in appropriatecases, be incorporated in standard fashion as virtual memory in Memory3124. Removable Medium 3114 may take the form of any of thecomputer-readable media described below.

Processor 3122 is also coupled to a variety of input/output devices,such as Display 3104, Keyboard 3110, Mouse 3112 and Speakers 3130. Ingeneral, an input/output device may be any of: video displays, trackballs, mice, keyboards, microphones, touch-sensitive displays,transducer card readers, magnetic or paper tape readers, tablets,styluses, voice or handwriting recognizers, biometrics readers, motionsensors, brain wave readers, or other computers. Processor 3122optionally may be coupled to another computer or telecommunicationsnetwork using Network Interface 3140. With such a Network Interface3140, it is contemplated that the Processor 3122 might receiveinformation from the network, or might output information to the networkin the course of performing the above-described zero-trust processing ofprotected information, for example PHI. Furthermore, method embodimentsof the present invention may execute solely upon Processor 3122 or mayexecute over a network such as the Internet in conjunction with a remoteCPU that shares a portion of the processing.

Software is typically stored in the non-volatile memory and/or the driveunit. Indeed, for large programs, it may not even be possible to storethe entire program in the memory. Nevertheless, it should be understoodthat for software to run, if necessary, it is moved to a computerreadable location appropriate for processing, and for illustrativepurposes, that location is referred to as the memory in this disclosure.Even when software is moved to the memory for execution, the processorwill typically make use of hardware registers to store values associatedwith the software, and local cache that, ideally, serves to speed upexecution. As used herein, a software program is assumed to be stored atany known or convenient location (from non-volatile storage to hardwareregisters) when the software program is referred to as “implemented in acomputer-readable medium.” A processor is considered to be “configuredto execute a program” when at least one value associated with theprogram is stored in a register readable by the processor.

In operation, the computer system 3100 can be controlled by operatingsystem software that includes a file management system, such as a mediumoperating system. One example of operating system software withassociated file management system software is the family of operatingsystems known as Windows® from Microsoft Corporation of Redmond,Washington, and their associated file management systems. Anotherexample of operating system software with its associated file managementsystem software is the Linux operating system and its associated filemanagement system. The file management system is typically stored in thenon-volatile memory and/or drive unit and causes the processor toexecute the various acts required by the operating system to input andoutput data and to store data in the memory, including storing files onthe non-volatile memory and/or drive unit.

Some portions of the detailed description may be presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is, here and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the methods of some embodiments. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the techniques are not described withreference to any particular programming language, and variousembodiments may, thus, be implemented using a variety of programminglanguages.

In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in a client-server network environment or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a tablet PC, a laptop computer, a set-top box (STB), apersonal digital assistant (PDA), a cellular telephone, an iPhone, aBlackberry, Glasses with a processor, Headphones with a processor,Virtual Reality devices, a processor, distributed processors workingtogether, a telephone, a web appliance, a network router, switch orbridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine.

While the machine-readable medium or machine-readable storage medium isshown in an exemplary embodiment to be a single medium, the term“machine-readable medium” and “machine-readable storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” and “machine-readable storage medium” shallalso be taken to include any medium that is capable of storing, encodingor carrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thepresently disclosed technique and innovation.

In general, the routines executed to implement the embodiments of thedisclosure may be implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions referred to as “computer programs.” The computer programstypically comprise one or more instructions set at various times invarious memory and storage devices in a computer (or distributed acrosscomputers), and when read and executed by one or more processing unitsor processors in a computer (or across computers), cause the computer(s)to perform operations to execute elements involving the various aspectsof the disclosure.

Moreover, while embodiments have been described in the context of fullyfunctioning computers and computer systems, those skilled in the artwill appreciate that the various embodiments are capable of beingdistributed as a program product in a variety of forms, and that thedisclosure applies equally regardless of the particular type of machineor computer-readable media used to actually effect the distribution

While this invention has been described in terms of several embodiments,there are alterations, modifications, permutations, and substituteequivalents, which fall within the scope of this invention. Althoughsub-section titles have been provided to aid in the description of theinvention, these titles are merely illustrative and are not intended tolimit the scope of the present invention. It should also be noted thatthere are many alternative ways of implementing the methods andapparatuses of the present invention. It is therefore intended that thefollowing appended claims be interpreted as including all suchalterations, modifications, permutations, and substitute equivalents asfall within the true spirit and scope of the present invention.

What is claimed is:
 1. A computerized method of processing input datacomprising: identifying a domain for a set of input data; validating theset of input data by range and distribution responsive to the domain;when the validating fails, transforming the input data by at least oneof a range transformation, a distribution transformation and a machinelearning (ML) transformation; iteratively validating and transformingthe input data until validation passes; and processing the validateddata using at least one algorithm.
 2. The method of claim 1, wherein thedomain is at least one of pathology dependent and financial use casedependent.
 3. The method of claim 1, further comprising cleaning theinput data.
 4. The method of claim 1, wherein the ML transform istrained on domain specific datasets.
 5. The method of claim 1, whereinthe validation includes comparing the datasets to an expected range anddistribution curve for the data domain.
 6. The method of claim 5,wherein the validation of expected distribution is a curve which fitswithin two standard deviations of the expected distribution.
 7. Themethod of claim 5, wherein the validation of expected distribution is acurve which fits within a configurable threshold of standard deviationsof the expected distribution.
 8. A computerized system of processinginput data comprising: a computer server for identifying a domain for aset of input data using an AI clustering model, validating the set ofinput data by range and distribution responsive to the domain using astatistical model, and when the validating fails, transforming the inputdata by at least one of a range transformation, a distributiontransformation and a machine learning (ML) transformation, anditeratively validating and transforming the input data until validationpasses, and processing the validated data using at least one algorithm.9. The system of claim 8, wherein the domain is pathology dependent. 10.The system of claim 8, further comprising a database for cleaning andstoring the input data.
 11. The system of claim 8, wherein the MLtransform is trained on domain specific datasets.
 12. The system ofclaim 8, wherein the validation includes comparing the datasets to anexpected range and distribution curve for the data domain.
 13. Thesystem of claim 12, wherein the validation of expected distribution is acurve which fits within two standard distributions of the expecteddistribution.
 14. The system of claim 12, wherein the validation ofexpected distribution is a curve which fits within one standarddistributions of the expected distribution.